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A  METHODOLOGY  FOR  DETERMINING  BMC4I  PARTICIPATING  UNITS 
(PUs)  INTEROPERABILITY  REQUIREMENTS 

EXECUTIVE  SUMMARY 

This  paper  describes  a  methodology  that  determines  System  Interoperability 
Requirements  for  forces,  participating  in  Joint  Operations  in  the  areas  of  Battle 
Management  Command,  Control,  Communications,  Computer  and  Intelligence 
(BMC4I).  From  the  perspective  of  Joint  Force  operations,  the  system  interoperability 
requirements  are  determined  at  the  force  level  as  follows: 

a.  Command  and  Control  Level  to  include  Force  Planning  and  Coordination; 

1.  Develop  Defense  Design, 

2.  Set  and  Enforce  Rules  Of  Engagement, 

3.  Respond  to  Battlefield  Changes, 

4.  Report  Force  Status. 

b.  Weapon  Level  Command  and  Control  to  include  Force  Execution; 

1 .  Control  Sensors  and  Weapons, 

2.  Direct  System  Engagements, 

3.  Report  System  Engagement  Status. 

Actual  system  interoperability  requirements  are  obtained  from  an  iterative 
process.  The  process  employs  Operational  Architectures,  Modeling  and  Simulation 
Tools,  Distributive  Interactive  Simulations,  Hardware-in-the-Loop,  and  Plug  and  Play 
Capabilities. 

The  methodology,  that  determines  the  BMC4I  participating  unit’s  force  level 
interoperability  requirements,  consists  of  a  set  of  logical  steps  that  are  iterative  by 
design.  It  provides  insights,  reliable  and  useable  estimates  of  numerical  measures  of 
force  level  system  requirements  at  several  levels  of  command.  The  process  is  not 
trivial;  the  expected  level  of  effort  could  be  significant  The  methodology  consists 
of  five  basic  stages  considered  necessary  to  achieve  valid  results.  These  stages  are: 

a.  Determination  of  force  level  system  requirements; 

b.  Determination  of  force  level  system  capability; 


c.  Analysis  of  force  level  system  capability; 

d.  Determination  of  force  level  system  requirements  by  battle 
overview  or  specific  scenarios  such  as  Southwest/Northeast  Asian; 

e.  Allocation  of  force  level  system  requirements  to  participating  units. 

This  methodology  can  be  used  by  Program  Managers  (PM)  for  determining  force 
level  BMC4I  system  interoperability  requirements  for  individual  participating  units  in  the 
battle  force.  In  addition,  once  the  participating  unit’s  performance  has  been  defined, 
the  methodology  generates  quantitative  data  bases  that  become  useful  tools  for  BMC4I 
system  suite  selection.  Once  alternative  suites  have  been  defined,  they  can  be 
analyzed  in  terms  of  the  specific  participating  unit’s  performance  capability  versus  cost. 

INTRODUCTION 

The  Joint  Theater  Air  Missile  Defense  Organization  (JTAMDO),  of  the  Joint  Staff, 
is  responsible  for  developing  the  Operational  Architecture  for  Theater  Air  Missile 
Defense  (TAMD).  The  BMC4I  Operational  Architecture  is  defined  as  a  description  of 
tasks,  operational  elements,  and  information  flows  required  to  accomplish  warfighting 
functions.  This  methodology  employs  the  following  Operational  Architecture  techniques 
to  develop  and  select  performance  options  for  participating  units: 

a.  Operational  Concept  Diagram; 

b.  Command  Relationship  Chart; 

c.  IDEFO  Activity/Functional  Model; 

d.  Participating  Unit  Information  Exchange  Requirements; 

e.  Required  Participating  Unit  Capabilities  Matrix;  and 

f.  Participating  Unit  Node  Connectivity  Model. 

The  goal  of  the  methodology  is  to  select  several  options  for  BMC4I  performance 
requirements  and  allocate  the  corresponding  BMC4I  requirements  to  participating  units 
to  meet  the  requirements  for  each  performance  option.  A  quantitative  data  base  could 
be  provided  as  a  tool  for  selecting  and  implementing  alternative  suites  for  participating 
units.  It  is  in  this  context  that  the  phrase  “participating  unit  requirements”  is  used.  In 
addition,  once  the  participating  unit’s  requirements  have  been  established,  alternative 
suites  are  generated.  The  alternative  suites  can  be  compared  in  terms  of  system 
capability  and  effectiveness  versus  cost. 
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PROBLEM  STATEMENT 


The  Battle  Management  Command,  Control,  Communications,  Computers,  and 
Intelligence  structure  glues  the  Battle  Force  together.  BMC4I  requirements  enable  the 
interoperability  of  participating  units.  During  the  employment  of  offensive  and  defensive 
operations,  BMC4I  implementation  emphasizes  the  synergistic  benefits  derived  from 
the  processes  of  joint  planning,  joint  coordination,  and  joint  execution1.  The  synergistic 
benefit  imparted  to  the  battle  force  is  that  the  cooperative  participation  of  individual 
participating  units  is  such,  that  the  total  effect  of  the  battle  force  is  greater  then  the  sum 
of  the  individual  participating  units  (capabilities)  acting  independently,  i.e., 

_  n  _  n  _ 

EMXI+YPU 'o^PUc 

X=1  x=\ 


The  task  is  to  establish  a  set  of  battle  force  BMC4I  requirements,  allocate 
requirements  to  the  mission  areas  across  the  Battle  Force,  and  allocate  the  functional 
requirements  to  the  individual  participating  units.  It  should  be  noted  that  allocating 
BMC4I  requirements  among  the  participating  units  is  a  difficult  task.  The  difficulty 
arises  from  a  defense  in  depth  concept  that  implies  multiple  participating  units  with  the 
same  redundant  requirements,  overlapping  areas  of  responsibilities  associated  with  the 
battle  force  participating  units,  and  common  capabilities  among  PUs. 

The  key  to  this  effort  is  to  establish  participating  unit  BMC4I  requirements  with 
the  necessary  definitions,  assumptions  and  tools  expressed  at  the  start.  In  particular,  it 
is  necessary  to  have  established  a  clear  and  agreed  upon  set  of  battle  force  BMC4I 
requirements  based  upon  battle  force  missions  and  their  corresponding  objectives.  It  is 
a  fundamental  task  requirement  that  the  definitions  be  expressed  in  measurable  form 
so  that  the  appropriate  measures  of  battle  force  capability  can  be  obtained.  The 
measures  of  performance2  include,  but  are  not  limited  to,  the  following: 

a.  Participating  unit  (network  node)  connectivity  performance; 

b.  Network/data  link  throughput  (information)  performance; 

1 .  Capacity:  the  rate  at  which  data  may  be  passed  over  time; 

2.  Network  loading  performance: 

(a)  Overload  condition:  where  the  volume  of  data  being 
exchanged  exceeds  the  transmit  capability; 

(b)  Under  utilization  condition:  system  data  rate/message  load  is 
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less  than  its  full  capacity  and  messages  are  waiting  in 
queues  to  be  transmitted  due  to  polling  schemes; 

(c)  Data  latency  performance  (timely  arrival  of  the  information); 

(1 )  Latency  of  Observation, 

(2)  Latency  of  Measurement/Performance, 

(3)  Latency  of  T ransmission  Receipt, 
d.  Estimates  of  Information  Utilization; 

1 .  Estimate  total  data/information  flow  rate; 

2.  Estimates  of  number/types  of  processing  errors; 

(a)  Track  steals, 

(bO  Dropped  tracks, 

(c)  Misclassification, 

(d)  Fratricide, 

(e)  Duplicate  engagements. 


PROBLEM  SOLUTION 

A  methodology,  that  determines  BMC4I  requirements  for  participating  units 
should  consist  of  a  set  of  logical  functions.  It  must  provide  insights  and  verifiable 
estimates  and  assessments  of  the  defined  BMC4I  force  requirements  at  each  level. 
This  process  is  not  trivial;  the  expected  level  of  effort  could  be  significant.  The 
actual  requirements  are  obtained  from  an  evolutionary  process  that  employs  Modeling 
and  Simulation  Tools  in  the  virtual  space  and  includes  Distributive  Interactive 
Simulations,  Hardware-in-the-Loop,  and  Plug  and  Play  Capabilities. 

A  BMC4I  requirements  methodology  has  been  developed  that  implements  the 
above  discussed  measures  of  performance  to  establish  battle  force  BMC4I 
requirements.  The  methodology  consists  of  five  stages  necessary  to  derive 
participating  unit  BMC4I  requirements.  At  the  Battle  Force  Command  and  Control  and 
Weapon  Control  level  the  five  stages,  illustrated  in  Figures  1  through  5,  include  the 
following: 
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a.  Determination  of  force  level  system  requirements; 

b.  Determination  of  force  level  system  capability; 

c.  Analysis  of  force  level  system  capability; 

d.  Determination  of  participating  unit  requirements  for  the  postulated  battle 
overview  for  specific  scenarios  such  as  Southwest/Northeast  Asian;  and 

e.  Allocation  of  force  level  requirements  to  participating  units. 

The  details  of  each  stage  are  shown  in  the  flow  charts  presented  in  Figures  1 
through  5.  The  flow  charts  illustrate  the  complexity  of  the  BMC4I  system  interoperability 
requirements  methodology. 
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Figure  1,  Stage  1,  provides  the  process  for  deriving  candidate  force  level  BMC4I 
system  interoperability  requirements;  allocating  the  requirements  to  BMC4I  systems; 
and  deriving  BMC4I  system  interoperability  performance  criteria. 


Figure  1 

Stage  1  -  Determination  Of  Force  Level  Requirements 
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Figure  2,  provides  the  process  for  selecting  appropriate  scenarios  and  candidate 
Modeling  and  Simulation  (M&S)  tools.  Stage  2,  executes  the  M&S  tools  and  gathers 
data  for  interoperability  requirements  analysis.  The  results  of  this  process  produces  a 
candidate  baseline  force  capability  defined  in  terms  of  Threat  Kill  versus  BMC4I 
capability. 


Figure  2 

Stage  2  -  Determination  Of  Force  Level  Capabilities 
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Figure  3,  Stage  3,  provides  the  analysis  process.  If  the  analysis  reveals  that  the  force 
mission  interoperability  requirements  have  been  met,  then  the  contributionfrom  each 
participating  unit  is  recorded.  The  methodology  continues  into  Stage  5  which 
determines  the  overall  battle  force  interoperability  requirements.  If  the  force  mission 
has  not  been  met,  the  mthodology  continues  into  Stage  4. 


Figure  3 

Stage  3  -  Analysis  Of  Force  Level  Capabilities 
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Figure  4,  postulates  additional  system  capabilities  to  meet  the  estimated  BMC4I 
interoperability  requirements.  The  methodology  returns  to  Stage  2,  inputs  the 
postulated  additional  capability,  and  iterates  the  M&S  tools. 


Figure  4 

Stage  4  -  Determination  of  TAMD  System  Requirements 
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Figure  5,  presents  the  process  that  examines  the  derived  interoperability  requirements 
across  all  scenarios  and  allocates  the  postulated  requirements  to  the  participating  units 
The  force  level  M&S  are  executed  to  validate  the  system  interoperability  requirements. 
If  all  system  requirements  for  all  scenarios  are  met,  the  set  of  BMC4I  system 
requirements  are  defined  for  implementation.  Otherwise,  the  scenario(s)  that  were 
found  to  be  deficient  are  identified  and  the  methodology  continues  in  Stage  4. 


Figure  5 

Stage  5  -  Overall  Battle  Force  Requirements  Determination 
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DEMONSTRATION 


This  section  presents  a  demonstration  of  the  methodology  which  begins  with  the 
following  scenario  or  battle  overview.  Two  neutral  cities  are  under  attack  from  Red 
Forces.  Blue  Force  have  arrived  on  station  with  the  mission  of  defending  the  neutral 
cities  by  countering  the  Theater  Air  and  Missile  threat.  The  threat  consists  of  two 
elements:  aircraft  (manned  and  unmanned)  and  missiles  (including  ballistic  missiles, 
overland  cruise  missiles,  air-to-air  missiles,  and  air-to-surface  missiles).  Individual 
aircraft  and  theater  missiles  pose  a  significant  threat  to  friendly  forces.  The  battle  force 
mission,  ideally,  would  be  to  destroy  or  degrade  the  adversary’s  command  and  control 
and  air  defense  capabilities  that  includes  identified  fuel  sites,  air  bases,  and  supply 
sites.  Failing  that,  system  self  defense  capability  would  be  used  to  engage  inbound 
threats. 

Therefore ,  the  battle  force  mission ,  derived  from  the  scenario  or  battle 
overview,  is  to  destroy  and  degrade  the  adversaries  command  and  control,  and 
air  defense  resources  and  capabilities. 

The  next  step  is  to  determine  the  battle  force  requirements.  The  force 
requirements  follow  directly  from  the  battle  force  mission,  but  are  more  specific.  For 
this  sample  battle  force  overview,  Joint  Forces  Operation,  the  battle  force  is  required 
to  defend  the  following  high  value  assets: 

a.  Lines  of  communications, 

b.  Logistic  facilities  (ports,  air  bases,  and  marshaling  areas),  and 

c.  Large  civilian  population  centers. 

In  an  attempt  to  quantify  the  battle  force  mission,  the  following  battle  force 
command,  control,  and  communication  requirements  have  been  selected  for 
implementation: 

a.  Reduced  battle  force  reaction  time, 

b.  Reduce  and  minimize  the  number  of  enemy  leakers, 

c.  Communication  availability  on  demand,  and 

d.  Effective  allocation  and  utilization  of  battle  force  weapons  inventory. 
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This  demonstration  will  focus  on  the  implementation  of  "communication 
availability  on  demand"  requirement  in  terms  of  participating  unit's  communication 
timeliness  requirements;  i.e.,  information  exchange  requirements3  between  participating 
units  within  the  battle  force.  The  timeliness  requirements  for  information  exchanged  are 
real-time,  near  real-time,  and  non-real-time.  These  timeliness  requirements  are  defined 
in  The  Theater  Air  Defense  Capstone  Requirements1  Document. 

a.  “Real-time  is  the  timeliness  of  data  or  information  that  has  been  delayed 
by  electronic  communication.  The  implication  is  that  there  are  no 
noticeable  changes  in  the  arrival  of  the  information.  Real-time  information 
is  exchanged  over  the  Joint  Composite  Tracking  Network. 

Consequently,  real-time  information  exchange  requires  the  information  to 
be  exchanged  in  <  0.5  seconds.” 

b.  “Near-real-time  is  the  timeliness  of  data  or  information  that  has  been 
delayed  by  the  time  required  for  electronic  communication  and  automatic 
data  processing.  The  implication  is  that  there  are  no  significant  delays. 
Near-Real-Time  information  is  exchanged  over  the  Joint  Data  Network. 
Consequently,  near  real-time  information  exchange  requires  the 
information  to  be  exchanged  in  <  12  seconds.” 

c.  “Non-real-time  information  exchange  is  assumed  to  mean  time  greater 
than  near-real-time  (Joint  Publication  1-02).  Non-Real-Time  information  is 
exchanged  over  the  Joint  Planning  Network.  Consequently,  non-real-time 
information  exchange  is  any  information  exchanged  in  >  12  seconds.” 

The  next  step  in  the  methodology  is  to  derive,  from  the  battle  force  mission,  each 
participating  unit’s  mission.  Each  individual  participating  unit’s  mission  is  a  function  of 
two  main  factors.  The  first  of  these  two  factors  is  the  participating  unit’s  designed 
mission,  which  as  it’s  name  implies,  is  determined  form  the  units  original  design.  A 
design  mission  for  an  AEGIS  ship  class  is  to  provide  Anti-Air  Warfare  (AAW)  threat 
detection,  localization,  combat  identification/discrimination/classification  (Positive 
Hostile  ID),  attack  and  kill  capabilities  against  all  types  of  enemy  aircraft. 

The  second  factor  is  the  overview  or  scenario.  The  scenario  can  modify  the 
participating  units’  battle  force  missions  as  a  consequence  of  different  alternative 
options.  The  extent  of  the  unit’s  actual  battle  force  mission  is  dependent  upon  the 
number  of  battle  force  options  and  the  availability  of  units  currently  supporting  other 
aspects  of  the  battle  force  mission.  For  example,  an  AEGIS  Cruiser,  assigned  to  a 
carrier  battle  group,  has  area  AAW  as  its  primary  mission.  It’s  modified  overview 
mission  could  be  supporting  the  Joint  Forces  Defense-in-Depth  operations.  The  AEGIS 
Cruiser  would  be  employed  as  part  of  an  active  air  defense  force  in  a  manner  that 
provides  multiple  “shot  opportunities”  along  the  entire  flight  path  or  trajectory  of  in 
bound  hostile  aircraft  or  missiles.  The  best  way  to  demonstrate  the  development  of  an 
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individual  participating  unit  is  to  consider  an  example. 

AEGIS  Cruiser  —  SAMPLE  OVERVIEW 


Design  Mission 

An  AEGIS  Cruiser,  assigned  to  a  carrier  battle  group,  provides: 

a.  On  an  individual  participating  unit  level,  target  detection,  localization, 
identification,  classification  attack  and  kill  capabilities; 

b.  Area  AAW  in  a  support  role  with  other  participating  units;  and 

c.  Ownship  self-defense  against  all  types  of  threats. 

Overview  Modified  Mission 

a.  Support  the  Joint  Forces  Defense-in-Depth  operations. 

Unit  Mission 


a.  Provide  support  to  the  Joint  Forces  Defense-in-Depth  operations; 

b.  Provide  area  AAW  in  a  support  role  with  other  participating  units; 

c.  Provide  for  ownship’s  self  defense  against  all  types  of  threats. 

AEGIS  has  taken  on  the  additional  responsibility  of  supporting  the  Joint  Forces 
Defense-in-Depth  operations  as  compared  to  its  design  mission  of  area  AAW. 

Now  that  the  participating  units  missions  have  been  specified,  attention  is 
focused  on  determining  the  communication  suite  objectives  for  each  participating  unit. 
The  communication  objectives  for  each  participating  unit  is  the  maximum  percentage  of 
communication  deficiencies  that  a  participating  unit  can  sustain  and  still  be  expected  to 
perform  its  unit  mission.  In  order  to  determine  the  communication  objectives  for  each 
participating  unit,  a  process  had  to  be  developed  that  allowed  for  the  quantification  of 
each  participating  unit’s  communication  capacity. 

The  process  developed  consists  of  three  parts,  the  first  of  which  is  the  formation 
of  the  participating  unit’s  baseline  equipment  table.  A  baseline  equipment  table  is  a 
listing,  in  table  form,  of  the  communication  suites  aboard  a  participating  unit.  For  the 
AEGIS  platform  used  in  the  sample  overview,  the  baseline  equipment  table  is  shown  in 
Table  1,  where  the  X’s  represent  the  communication  suite  of  equipment;  and  Y’s 
represent  the  communication  channels  and/or  corresponding  communication  circuits. 
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TABLE  1.  AEGI 

S  COMMUNICATIO 

NS  BASELINE  EQUIPMENT  TABLE 

COMM 

DATA  LINKS 

NUMBER  OF 

COMMENTS 

SYSTEM 

CHANNELS 

OR  CIRCUITS 

JOINT 

COOPERATIVE 

COMPOSITE 

XI 

Y1 

ENGAGEMENT 

TRACKING 

CAPABILITY 

NETWORK 

X2 

Y2 

LINK  11  TADILB 

JOINT  DATA 

NETWORK 

X3 

Y3 

LINK  16  TADIL  J 

X4 

Y4 

TACT  INTEL 

BROADCAST 

BROADCAST 

SYSTEM 

X5 

Y5 

TRAP  DATA 

DISTRIBUTIVE 

SYSTEM 

After  a  baseline  equipment  table  has  been  formed  for  each  participating  unit  in 
the  battle  force,  it  is  time  to  generate  the  second  part  of  the  quantification  process,  the 
unit  mission  minimum  equipment  table.  As  its  name  implies,  this  table  list  the 
minimum  equipment  that  a  participating  unit  must  have  to  perform  its  unit  mission.  The 
minimum  must  not  exceed  the  baseline  level.  If  a  participating  unit’s  communication 
suite  has  performance  deficiencies,  its  baseline  capability  can  be  increased.  Ideally, 
the  temporary  equipment  allocation  identifies  the  need  for  additional  systems 
requirements  and  capabilities. 

The  minimum  equipment  table  is  not  a  concrete  item,  but  is,  rather,  set  by  the 
user’s  experience  with  the  participating  units  mission.  For  AEGIS  the  minimum 
equipment  level  was  set  as  shown  in  Table  2.  Using  the  AEGIS  unit’s  mission,  it  is 
fairly  easy  to  see  how  the  minimum  equipment  levels  were  set  in  terms  of  the  minimum 
number  of  communication  channels  or  circuits.  The  minimum  number  of 
communication  channels  or  circuits  is  a  judgment  call  on  the  part  of  the  user  of  this 
methodology.  Since  this  methodology  calls  for  several  iterations  about  the  baseline, 
one  will  know  if  his  choice  of  the  minimum  number  of  channels  or  circuits  was  too  high 
or  too  low  for  the  specific  overview. 

The  Third  part  of  this  process  is  one  that  actually  quantifies  the  participating 
unit’s  communications  capabilities.  Quantifying  the  AEGIS  communication  system 
performance  requires  the  development  and  implementation  of  sets  of  communications 
measures  of  performance  and  effectiveness.  Reference  (2),  Interoperability 
Assessment/Analysis  Tool,  provides  a  methodology  that  quantifies  BMC4I  Systems 
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Interoperability5.  It  should  be  noted  at  this  point,  that  the  Interoperability  Assessment 
Tool  methodology  was  used  to  quantify  the  AEGIS  communication  system  objectives. 
The  methodology  identifies  and  defines  nine  BMC4I  Interoperability  system 
components  (Requirements,  Standards,  Data  Elements,  Node  Connectivity,  Protocol, 
Information  Flow,  Latency,  Interpretation  and  Information  Utilization).  The  next  step  in 
the  quantification  process  is  to  match  up  the  AEGIS  Baseline  Communications 
Minimum  Equipment  Table  with  the  nine  interoperability  components.  The  results  of 
this  step  enables  the  selection  of  the  specific  measures  of  performance  and 
effectiveness  that  will  be  used  in  quantifying  AEGIS  communication  system 
performance. 


TABLE  2. 

AEGIS  BASELINE  COMMUNICATIONS  MINIMUM  1 

EQUIPMENT  TABLE 

COMM  SYSTEM 

DATA  LINKS 

#  OF  CHANNELS 
.OR  CIRCUITS 

COMMENTS 

JOINT 

X 

COOPERATIVE 

COMPOSITE 

Y1 

ENGAGEMENT 

TRACKING 

NETWORK 

CAPABILITY 

. . .  '”'1^ 

X  X2 

Y2 

LINK  11  TADILB 

JOINT  DATA 
NETWORK 

Y3 

LINK  16  TADIL  J 

X4 

Y4 

TACT  INTEL 
BRDCST  SYSTEM 

BROADCAST 

X5 

Y5 

TRAP  DATA 
DISTRIB  SYSTEM 

The  next  step  in  the  process  is  to  obtain  a  set  of  computer  models  and 
simulations  that  best  fit  the  Interoperability  Assessment  Tool  methodology.  The  next 
step  substitutes  the  following  baseline  input  data  into  a  Battle  Force  Simulation(s)  such 
as  Extended  Air  Defense  Simulation  (EADSIM),  or  Extended  Air  Defense  Testbed 
(EADTB). 

a.  Real-Time-Information  Exchange  Requirements  <  0.5  seconds; 

b.  Near-Real-Time  Information  Exchange  Requirements  <12  seconds;  and 

c.  Non-Real-Time  Information  Exchange  Requirements  >  12  seconds. 

It  should  be  noted  that  there  are  many  other  models  and  simulations  that  will 
work  well  with  the  Interoperability  Assessment/Analysis  Tool.  The  EADTB  tool  was 
selected  for  the  following  reasons: 
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a.  It  was  specifically  designed  with  BMC4I  communication  requirements  in 
mind,  and 

b.  It  provides  a  perfect  fit  with  the  Interoperability  Assessment/Analysis  Tool. 

It  should  be  reiterated,  however,  that  the  specific  model  chosen,  while  important, 
is  not  vital  to  the  Interoperability  Assessment/Analysis  tool. 

SUMMARY 

This  paper  has  presented  and  described  a  methodology  that  identifies, 
quantifies,  and  establishes  Battle  Force  BMC4I  Participating  Unit  requirements.  The 
methodology  presented  in  this  paper  has  the  potential  for: 

a.  Identifying,  isolating  and  resolving  Battle  Force  BMC4I  problem  areas 
and  issues,  and 

b.  Setting  participating  units  BMC4I  system  requirements. 

The  methodology  is  currently  being  implemented.  Once  results  have  been 
obtained  and  analyzed  the  corresponding  participating  unit  requirements  will  be 
published.  After  the  methodology  has  been  refined,  it  will  be  capable  of  setting  combat 
system  requirements  across  all  Battle  Force  Warfare  Areas  for  all  types  of  participating 
units.  The  logical  expansion  of  this  methodology  derives  “required  forces”  for  given 
scenarios.  The  first  successful  iteration  will  establish  that  an  acceptable  level  of 
performance  has  been  determined.  Further  iterations  may  be  necessary  to  establish 
the  most  cost  effective  asset  utilization;  e.g.,  a  Patriot  Missile  Battery  or  an  AEGIS 
Cruiser/Destroyer  could  be  reassigned  to  other  missions. 
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